This rewrite ends up comparing two different things - "calling" and "events".
I suggest we either keep the original phrasing ("Unlike "native" events...")
OR
break it down into two sentences and also change the voice to active to differentiate between browser and developer actions. ("when you call" is a subtle hint that you call this method manually)

What do you think about:

@Josh-Cena could you cross-check the technical accuracy of my suggestion here. Thanks!

This looks right to me :) I would suggest:

@Josh-Cena - but that phrasing brings back the technical confusion/inaccuracy that this PR aims to correct from the first place.

Correct me if I'm wrong.

The difference to "native" - is that the call for the dispatch itself is async, but during it, event listeners run synchronously - don't go up the event loop.

The statement

"each event handler is executed asynchronously[...]"

makes it sound as if each of them is scheduled asynchronously on the event loop.

Interestingly, I tried to physically verify this by running some code in the console:

const btn = document.createElement('button'); 
btn.textContent = 'click me'; 
document.body.appendChild(btn); 
btn.addEventListener('click', () => { 
   console.log('listener 1 start'); 
   Promise.resolve().then(() => { 
      console.log('microtask from listener 1'); 
   }); 
   setTimeout(() => { console.log('timeout from listener 1'); }, 0); 
   console.log('listener 1 end'); 
}); 
btn.addEventListener('click', () => { console.log('listener 2'); }); 

The microtask log does run between listeners, the timeout log only after both run.
When running the same principle with a manual dispatchEvent and a custom event - the microtask log only shows after both listeners run. In native - there is a microtask checkpoint between listeners. But, still - the listeners themselves doesn't run async, no separate async queuing for each...
Or are they...? I mean, this test shows at least that no async timers run between (tried with other types of asyncs as well - same result) - my only doubt is that maybe they DO - and have a different "async priority" / are queued as a batch.
There is no place in the specs that explicitly says they run async in native, anyway.

What is the definite proof...?

EDIT: I'm learning to read the specs / distinguish between the terms, and it definitely says the handlers are "called" and not queued.

Wait, now I'm not sure what the issue is claiming.

For a "native" event:

1. The browser receives a mouse click; it enqueues all registered event handlers on the task queue.
2. At some indefinite time in the future, the event handler is successfully dequeued from the task queue and gets executed. It's asynchronous in the sense that it doesn't reuse the job of any other JavaScript execution—it's the entrypoint of a whole JavaScript job. It's synchronous in the sense that the browser doesn't "await" it, whatever that should mean when there's no relevant return value anyway.

Imagine this:

btn.addEventListener("click", function onclick1() { foo(); });
btn.addEventListener("click", function onclick2() { bar(); });

The job queue:

job 1: whatever code is currently running
job 2: click event handler 1
  stack frame 1: onclick1()
  stack frame 2: foo()
job 3: click event handler 2
  stack frame 1: onclick2()
  stack frame 2: bar()

When job 2 executes, onclick1 may schedule more jobs via setTimeout, new Promise, etc. Because new Promise makes a microtask with higher priority, when job 2 finishes, the next task the browser picks out will be the microtask instead of job 3, which has to wait a bit more. This is the speculation behavior you have observed.

For dispatchEvent:

1. The function gets called. All registered event handlers get called synchronously.
2. Each event handler executes in the current JavaScript job. It's definitely synchronous by every definition of synchronicity.

The job queue:

job 1: whatever code is currently running
  stack frame 1: dispatchEvent()
  stack frame 2: onclick1()
  stack frame 3: foo()
  ...
  stack frame 2: onclick2()
  stack frame 3: bar()

Nothing is allowed to execute between onclick1() and onclick2() because it's one synchronous block.

My acceptance of the original issue was that the word "asynchronous" is ambiguous in the context of native events because an event handler cannot observe its asynchronicity anyway, when by definition it has no relevant caller or callee. The key point here is that the event handler executes in a separate JavaScript job.

Now I look back at your suggestion, I don't think it makes a lot of sense either:

Unlike "native" events, which are fired by the browser and invoke dispatchEvent asynchronously via the [event loop]

You are implying the following:

job 1: whatever code is currently running
job 2: all click event handlers
  stack frame 1: dispatchEvent()
  stack frame 2: onclick1()
  stack frame 3: foo()
  ...
  stack frame 2: onclick2()
  stack frame 3: bar()

This would mean no other job is allowed to execute between onclick1() and onclick2(). This is false.

So I think there's something to be rewritten about this paragraph, but not your suggestion verbatim. Sorry I didn't read your suggestion in detail when I triaged the issue.

As far as I understand, the mental model (for native events) is more like:
job 1: start internal event dispatch process, which are these steps:
https://dom.spec.whatwg.org/#dispatching-events
these include, for each of the 3 phases: capturing, target, bubbling:
cloning the event handlers registered on each EventTarget object along the "event path" - and calling them one-by-one (like in a for-loop. Specs say: "For each"):
https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke

the key point/question here, again, is if they are called "asynchronously" (as in what JS developers usually expect when they see this term) or not;
They are called in what the specs define as "callback invocation"
https://webidl.spec.whatwg.org/#js-invoking-callback-functions

which, as I'm researching thus far, is not the same as what variations of "running asynchronously" usually mean. It is a specific mechanism, that includes cleanup and microtasks checkpoint after each, but not a "macrotask" checkpoint.
i.e. Promises/Microtasks queued from a listener will run when it's done, but any other "async macrotask" will only run after ALL listeners finished running.

I've seen all sorts of discussions surrounding this, and I also saw this:
whatwg/dom#1308
(A proposal for "asynchronous event listeners" - which I think strengthens my point that event listeners are not considered "asynchronous" in the common/usual way).

so, I think what's actually happening is something that's between the first model you describe in your comment and the second one (that you describe as what I was implying).

And in that model: queued microtasks will run in-between, queued macrotasks will not run in-between, only after.

The issue may be mostly "technical semantics";
I still think the current phrasing:

Unlike "native" events, which are fired by the browser and invoke event handlers asynchronously via the event loop

does not reflect what is technically happening; Event handlers do not go up the event loop the same way other "usual" async tasks usually do.

Not all native events are fired in their own task (and thus spawn a new stack per callback, which itself will enter the microtask checkpoint when cleaning).
For instance the <iframe>'s load event will fire synchronously at document insertion if its src is about:blank: https://jsfiddle.net/0cus135z/

@Kaiido Interesting.
BUT... your code calls document.body.append(i); - which is conceptually like calling element.click() (it's a different kind of "dispatch" - it spawns from JS - like an "artificial click" - meaning it's not a "native event" "conformally" - it doesn't come from "outside" (e.g. an actual mouse click detected by the OS );

Note that once I put the iframe in the html (without src) - and even set src to about:blank from JS - the expected behavior happens.
See variant of your jsfiddle: https://jsfiddle.net/eqt29b6x/2/

Or it could be that the createElement of the iframe from JS is what's making the difference - this can make sense because in the first variation JS is the source of creation of the iframe, and in the second variation it's the HTML parser - which is in the host/Blink layer - so this also might be the reason for the load behaving differently between variations - it's like a "native load".
Either way I don't think it shows an exception.

Also I saw this:
whatwg/html#4965
But not sure is related or even relevant anymore as my first paragraph above suggests.

I'm going to try to commit the PR with dipikabh phrasing from yesterday - in about two more days (to allow some more time for any other "possible exceptions").

I'm not sure everyone will understand this term that way. For me at least, a "native event" is an event fired from the UA itself, and not one generated by the user code that would be dispatched by a direct call to dispatchEvent (or by a wrapper like HTMLElement.click()).

Other such events I know of, that would fall into my definition of "synchronous native events": <form>'s formdata and <input> invalid events when the form is submitted programmatically, AbortSignal's abort event (even when tied by AbortSignal.any()), <dialog> before toggle when triggered from close(), popstate when setting location.hash. But there may be many more in APIs I don't know. Events have to be fired from a task only when "the algorithm that triggers the event could be running on a different thread or process" (https://w3ctag.github.io/design-principles/)

Also, while I believe this might be a bug, in Firefox, beforeinput and input events do fire synchronously, even though they'd fall in your definition.

I would define "native event" as "anything that does not originate from within the runtime of Javascript".
This also aligns with the quote you mention from the design specs - and also with your examples.

Meaning: "if you do it from JS - it's not a "native event"". I think this definition holds - also aligns with your examples - e.g. "submit with JS" vs. the browser's "native submit" (a button with type="submit" inside a form).

I would also argue that possibly any API implementation parts that ARE in JS actually call dispatchEvent.

"native events" are "system events" --- the obvious examples are things like mouse click - but are also true for something that happens in the "outer host browser level" - "browsery things".

The most important insight and anecdote I've learned from all of this is to remember that Javascript still keeps its original intention of acting as an "interface" to "outer" or "native" capabilities (it started as a "scripting language to interface with the browser" after all) - and those widened incredibly far over the years - but this truth still holds.

The mental model is seeing this single V8 thread as the "inside", and the host browser and beyond as the "outside". If it's triggered "programmatically" with JS === not "native".

Come to think of it - there is no "official definition" in MDN of what a "native event" is (at least, I asked chat GPT to check and it says there isn't), while "fired by the user agent" IS sometimes used in specs, so maybe we should use:

Unlike calling dispatchEvent() manually, which triggers event handlers to run synchronously in the same stack frame, "native" events - originating from the browser environment, triggers each event handler to run on a separate stack execution frame; any queued microtasks run after each event handler. However, other asynchronous browser operations, such as rendering, run only after all event handlers have finished running.

@Josh-Cena @dipikabh Looking at this text ^^^ it seems pretty unhelpful to me - should I as a user of this method need to understand stack frames or microtask? No, no I should not - certainly not for this method where knowing this makes no difference.

This was also discussed in #43973, where we were converging towards something like this:

It is possibly not quite correct, but it captures the main point of the original, which is that these events are synchronous, whereas events generated by the browser are not.

Anyway, my take on this is that something simple here is better or deleting the text entirely, as largely irrelevant to readers.

I'll leave to you, and close the other issue as it was "late to the party".

... or if you leave it to me, I'll just delete this section altogether :-)

The fundamental question is whether there's race—i.e., if it's possible for other jobs to execute in between two event handler executions.

Following @hamishwillee comment about not being too "low-level-ish" (though I argue about his remark regarding microtasks - modern JS developers are familiar with the concept, especially as queueMicrotask is an official API, MDN also has a guide on it (added a link to it in my suggestion), plus the event loop is mentioned - it's just the same amount of "low-level", if not more) I ) and in the spirit of this paragraph being about "native events VS. user events", I now suggest changing to adding this note (while removing that paragraph)

@Josh-Cena @dipikabh Looking at this text ^^^ it seems pretty unhelpful to me - should I as a user of this method need to understand stack frames or microtask? No, no I should not - certainly not for this method where knowing this makes no difference.

This was also discussed in #43973, where we were converging towards something like this:

It is possibly not quite correct, but it captures the main point of the original, which is that these events are synchronous, whereas events generated by the browser are not.

Anyway, my take on this is that something simple here is better or deleting the text entirely, as largely irrelevant to readers.

I'll leave to you, and close the other issue as it was "late to the party".

@hamishwillee I disagree about the comment about should they be familiar with what a microtask is. Yes - they should, queueMicrotask is official API. MDN has this guide: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide.
The event loop is mentioned - which is an even "lower-level" concept.

I think the questions regarding about whether this paragraph should exist, and if so - is this the right place, are:

• Would a reader of the dispatchEvent page will likely be interested in a quick summary of the differences between "custom and native"? I say: yes.
• What would represent the practical differences? I say: mainly the microtasks difference, the non render between handlers, then I also think the isTrusted.

On the other hand - your last suggestion is short and concise - and does "fix" the technical semantic "mistake" that triggered me to open this PR.

The fundamental question is whether there's race—i.e., if it's possible for other jobs to execute in between two event handler executions.

@Josh-Cena If this is the fundamental question/problem then IMO should be addressed directly rather than highlighting that some things are sync and others are async. I.e. start with the problem.

@yuval-a As a general principle I think we will have to agree to disagree on microtasks - most programmers most of the time do not need to care about that level of detail. Of course it may be that this is a case where the problem can't be explained without them. Fortunately I'm not the reviewer, so I don't need to assess that.

The paragraph on isTrusted seems useful YOu might consider a few words on why it matters (in addition to the link)

@hamishwillee I thought about just mentioning Promises but it sounds too partial.
Anyway, I think the subject of "do we go there?" about Microtasks - is like a "standards/specs" question. I'm not a long-running contributor to MDN - I came here because I was triggered by the phrasing of that paragraph - but do MDN have a formal "standards" document? like a "style guide"? If not, it should - I was going per what I know already exists. But anyway I emphasis again that I think it's very legit to use that term;

1. As I mentioned there's actually an official global method with that term in its name (for me that alone is enough to justify it).
2. Microtasks is the de facto mechanism of "asynchronicity" in Javascript - before it existed it was just "offload to the host browser" for async. To the best of my knowledge adding it was a design choice spawned from: "We need a way to allow these "clean-up/just-before" tasks inside Javascript. It's used for Promise resolve callbacks, but also for Custom Elements reactions, MutationObserver callbacks and likely other stuff. It's a thing in Javascript, like, a major thing.

Anyway, a compromise would be to mention Promises instead and add "Microtasks" parenthesised. Also, I'm leaning more and more towards a note that explains the two different types of events.

This is my next suggestion:

@yuval-a Thanks. I think this is getting htere ^^^. I wouldn't necessarily have (all of) it as a note because it isn't really all aside material. You would want to tidy this bit "scheduled from event handlers of "synthetic events will run only after all event handlers have completed running." because it compares event handlers and event handlers without differentiation of the types you mean.

But I am leaving this to @dipikabh and @Josh-Cena